The present application relates generally to an improved data processing apparatus and method and more specifically to mechanisms for performing security role testing using an embeddable container and properties object.
One of the application program interfaces (APIs) available in the Java programming language is the Enterprise Java Bean (EJB). EJB was originally developed by International Business Machines Corporation of Armonk, N.Y., in 1997 and later adopted by Sun Microsystems in 1999. EJB is a server-side model that encapsulates the business logic of an application and thus, provides a managed, server-side component architecture for modular construction of enterprise applications. The EJB specifications provide a standard way to implement the back-end business code typically found in enterprise applications, as opposed to front-end interface code. EJBs are intended to handle concerns that are common to enterprise application code such as persistence, transaction integrity, and security in a standard way leaving programmers free to concentrate on the particular problems to be addressed by the enterprise application.
EJB applications contain security role information for each method in the EJB. This security role information defines what security roles are permitted to execute the particular method. Thus, if a user has a first security role and attempts to execute methods in an EJB, the first security role may be compared against the security role information defined for the methods of the EJB and determine which methods of the EJB may be executed by this user and which cannot. Thus, the user with the first security role may be able to execute a first set of methods of the EJB and a second user having a second, and different, security role may be able to execute a second set of methods of the EJB which may be different from the first set of methods of the EJB.
Currently, there is no efficient way for Java developers who are developing EJBs that utilize security roles to test the correctness of the role security definitions in the EJB. That is, with the current developer environment, in order for an EJB developer to test the EJB's security role definitions, the EJB developer must perform the following operations:
(1) install a Java Enterprise Edition (JEE) application server, such as Websphere available from International Business Machines Corporation;
(2) start the application server;
(3) configure the application server to have security enabled and have a user registry;
(4) define the necessary users, groups, and passwords in the user registry;
(5) install the EJB application on the application server;
(6) map the EJB's security role definitions to users and/or groups in the user registry;
(7) start the EJB application on the application server;
(8) invoke another program, such as a servlet, to supply a valid user id and password which then invokes the EJB application (if an invalid user id and password is entered, then another user id and password is entered and the process repeated until a correct user id and password are entered); and
(9) examine the output of the EJB application, or the application server logs, to look for any messages indicating a security violation while invoking the EJB application's methods. For any subsequent changes made to the EJB's security roles, the EJB developer must uninstall the EJB application from the JEE application server and then repeat steps 5 through 9 above for the updated EJB application.
As can be seen from the above, this process for verifying that the security role definitions of an EJB application are coded can be very slow and cumbersome, especially during the early stages of the EJB development lifecycle. As a result, EJB developers have a tendency to perform security role testing at a later phase of the EJB development lifecycle which adds to the development cost for developing an EJB application.